1. Technical Field
The present invention relates generally to data transfers, and more particularly, to a method, system and set of signals for completing a data transfer using a single transfer request.
2. Related Art
In computer systems, the main components communicate with each other through an information pathway called a bus. A bus is a standardized interface allowing communication between initiators, called masters, and destination components, called slaves. The nature of the data transferred between a master and a slave may vary both in the amount, and its address alignment. Data transfer sizes may vary from one byte of data up to hundreds, or even thousands, of bytes.
“Address alignment” refers to the starting and ending memory address locations of the data transfer. A data transfer is “aligned” if all of its data beats utilize all of the byte lanes of the bus. A “data beat” is defined as a transfer of data across the bus, full width or less, in one time interval or clock cycle. Alignment and use of all byte lanes during data transfers produces maximum bus throughput and overall system performance. In order to achieve alignment, the starting address and the total size of a transfer must be a multiple of the bus size. For example, with a 4-byte bus, aligned transfers must have a starting address that is a multiple of 4 (i.e., 0, 4, 8, etc.), and their total size must be a multiple of 4. A data transfer is “unaligned” if one or more of its data beats does not use all of the byte lanes of the bus. In order for this to occur, either the starting address or the total size of the transfer (or both) must not be a multiple of the bus size. For example, with a 4-byte bus, if the starting address is 2 (not a multiple of 4), then the first data beat of the transfer will only use two of the bytes of the bus. Another example, again with a 4-byte bus, is a transfer of 6 bytes (again, not a multiple of 4). In this case, even if the starting address is a multiple of 4 (e.g., address 0), then the first data beat will be aligned (i.e., using all four bytes of the bus), but the second data beat will be unaligned because it will only use two of the bytes of the bus. Note that a transfer for which the starting address is not a multiple of the bus size may result in both the first and the final data beats being unaligned. For example, with a 4-byte bus, a transfer of 8 bytes with a starting address of 2 will result in: a first data beat of an unaligned transfer of 2 bytes (addresses 2 and 3), a second data beat of an aligned transfer of 4 bytes (addresses 4–7), and a final data beat of an unaligned transfer of 2 bytes (addresses 8 and 9).
In most computer and communication systems, data transfers may begin unaligned, end unaligned or both. However, the emerging use of various information data packet protocols that allow packet sizes of an arbitrary number of bytes presents an increasing number of unaligned transfers, which reduce bus throughput and overall system performance. Unaligned data transfers present additional problems when the transfer requires multiple data beats (i.e., cycles) of the bus. In particular, a master must make potentially three different transfer requests for each data packet when the data transfer starts and ends unaligned. For example, a data transfer of 86 bytes that starts and ends unaligned and is made across a 128-bit data bus may require three separate transfers. For example, a first partial data bus transfer request as a single request of 11 bytes, an aligned burst transfer request of 64 bytes, and finally another partial data bus transfer request of 11 bytes. In this case, the master has to have the associated extra logic to perform address alignment up to and following the burst transfer. Another issue with this technique are delays caused by bus arbitration. In particular, a master has to arbitrate amongst other masters requesting data transfers. As a result, delays between portions of a multiple beat unaligned data transfer may occur due to other masters winning arbitration and performing their transfer request(s). This can delay the overall data packet delivery significantly and interrupt an isochronous data transfer protocol.
One technique for addressing multiple beat, unaligned data transfers has been to perform an open ended burst transfer and treat each data beat as a separate transfer. In this case, each data beat is supplied with all the information required for a transfer including, in particular, byte enables. This technique, however, does not allow byte enable signals to be used for subsequent transfer requests after the initial request is made, which requires each data beat to include byte enable signaling. Accordingly, this technique may generate significant signaling requirements for a multiple beat transfer, which increases circuitry and bus switching demands for each data beat, which increases power consumption. This technique also does not provide the slave with the entire payload size at the start of the transfer, which is useful for the prefetching of read data and time allocation of write buffers.
The above technique also presents a problem relative to “pipelining” of data transfers. Pipelining of data transfers involves broadcasting pending master data transfer requests to slaves during the busy state of the data bus(ses). Pipelining allows slaves to allocate resources or prefetch data prior to their respective data tenure on the requesting bus, which reduces latency and increases bus throughput. In order to address pipeline transfer requests, two sets of byte enable signals would be required with the above technique, i.e., one for data tenure and one for pipelined address tenure. Dividing large unaligned data transfers into multiple transfer requests diminishes the advantages of pipelining because the slaves must handle an increased number of requests, and do not know at the transfer start whether multiple such requests by the same master constitute a single transfer of an unaligned portion of data.
In view of the foregoing, a need remains for efficient and simple data transfers that do not suffer from the problems of the related art. Specifically, a need remains for a technique for efficiently communicating both the starting and ending data alignments for multiple beat data transfers as part of the initial transfer request.